IBIS Macromodel Task Group Meeting date:20 July 2021 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki * Ming Yan Todd Bermensolo * Rui Yang Luminous Computing David Banas Marvell Steve Parker Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to send BIRD211.3 draft 2 to ATM for final review. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 13th meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD211.3 draft2: Fangyi shared the draft. Bob noted that references such as, "On page 201 after section 10.2.3" might need to be adjusted, since this BIRD will now be relative to IBIS 7.1, not IBIS 7.0. Bob said he was still unclear about the paragraph that starts with: Note that EDA tools, for AMI models with AMI_Version 7.2 and later, are allowed to determine the model filter impulse response by adding an aggressor column that contains a "unit impulse response" to determine the filter equalization. He asked how this was related to Tx_Impulse_Input. Others replied that this is independent of the Tx_Impulse_Input parameter. The aggressor columns have always been available, but IBIS 7.1 will be the first time the specification states that model makers should be aware of and handle the possibility of an EDA tool passing in a "unit impulse response" dummy aggressor column. Walter noted that tools could always have employed this technique, at their own peril, and since no known AMI model optimizes its equalization based on crosstalk it would be fine. Only a future model that optimizes its equalization settings based on crosstalk columns would have to worry about special handling of a unit impulse response dummy column. Ambrish moved that we delay the final review until next week, so everyone has time to fully review draft2. Bob seconded. There were no objections. PAMn BIRD213 discussion: Walter said he had made some additions to a BIRD213.1 draft, and he briefly reviewed them. He noted that one major addition was a definition and explanation of duobinary. Walter observed that you don't get more data per UI with duobinary, like you do with other PAM3 flavors, or PAM4, etc. But duobinary makes sure your voltages stay centered around zero, so you don't have issues with DC drift. Arpad asked if PAM3 and duobinary are two different things. Walter said both have 3 levels, but it's a question of how the levels are mapped. One typical PAM3 is the 11/7 encoding, where 11-bit patterns are mapped to 7 three-level symbols. In duobinary you get a one to one mapping of bits to symbols, no density gain in terms of information per UI. Fangyi said he disagreed with the stated definition of duobinary. He said another implementation is an adder that adds the previous bit to the current bit, and it is like a low-pass filter that effectively lowers the bandwidth of the signal. Fangyi said there are many flavors. Walter agreed and said we could leave the definition as a future exercise and plan to expand and refine it. Arpad asked, if there were many flavors of doubinary, and many mappings for bits to symbols in other PAMn schemes, then what's the best approach for handling them in the specification? He said it's probably not good to try and enumerate all the possibilities. Would something with expressions or equations be more appropriate than static tables and allow us to include dependence on previous bits? Walter reviewed the PAM_Mapping_Table and the examples showing how each row in the table maps an M-bit binary pattern into a pattern of N n-level symbols (e.g., M=11, N=7, n=3, for the 11/7 PAM3 mapping). Fangyi noted that this approach works when the mapping does not depend on previous history. Walter agreed that it doesn't work for duobinary, for example, and we will have a special case for that. Arpad asked if the 11 bits (11/7 example) in each row's bit pattern are successive bits in time. If so, is the right-most bit the first in time or the left-most? Fangyi and Walter agreed that this was a good question and we should clarify the intent. Curtis asked if we would really want to have to specify 2048 lines (2 to the eleventh) to enumerate each of the possible 11-bit patterns in 11/7. Ambrish asked what the point of the table was and whether we should be enumerating such things inside the specification. Walter said he had originally thought we should not include the mapping in the specification, but others had argued to include it in his BIRD. He said a tool might randomly generate 3-level symbol patterns for a PAM3 case, but there is the issue that not all 3-level sequences are allowed. Do we care? You might also generate a mapping that avoids the "lonely 1" bit pattern that can cause problems with drift and other issues, for example. Ambrish asked if the IBIS specification is where we should be defining the specifics of the mappings. Arpad agreed and said this went back to his question about whether or not we should be trying to hard code every flavor and enumerate things in the specification. Walter suggested we could simply provide the PAM_Mapping_Name, and another document could provide the definitions of the mappings. Arpad said the BCI protocols provide a precedent for having externally supplied definitions. Walter said that this case is slightly different, since the tool will have to be aware of the PAMn mapping details. Fangyi suggested we might just define the names and expect that the tools should know what they mean. Walter asked, who would be the keeper of the official list of supported names? Randy noted that we hadn't yet really solved the issue with respect to a process for publishing BCI protocols, but that we might do something similar here. - Randy: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Walter to send BIRD213.1 draft 2 to ATM for people to review. ------------- Next meeting: 27 July 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives